essayedit button

AI, 그리고 Frontend

18 min read|25. 7. 2.

개발자는 스스로 자신들의 직업을 없애는 유일한 직군이다. 이런 말이 있을 정도로 최근 AI의 발전을 지켜보면 더이상 개발자가 필요 없을지도 모른다.

여전히 다양한 토론이 오고 가는 이 주제에 대해 이야기 하려고 한다. 개발자라는 직업 전반에 대해 이야기 하기엔 경험이 부족하기 때문에 내가 속해있는 분야에 한해서 몇 가지 생각을 정리하려고 한다. 불확실성이 가득한 시대다. 느낀 생각들을 글로 정리해도 금방 옛것이 되어버린다. 그래서 이렇게 시간들여 정리하는 것이 무의미할 수도 있다.

사실들

우리는 AI가 만든 변화와 AI와는 상관없이, 원래 그랬던 것을 구분해야 한다. 원래도 그랬던 것인데 괜히 부풀려진 것이 많다. AI가 만든 변화를 사실 중심으로 살펴보자. 직접적인 예시는 글의 주제인 프론트엔드 개발 생태계를 중심으로 덧붙일 예정이다.

구현이 쉬워졌다.

모든 업계는 생산성을 높이는 방향으로 발전한다. 기술 생태계도 마찬가지다. 무언가를 만드는 일은 계속해서 쉬워진다. 웹 뿐만이 아니다. 리서치도 디자인도 더 쉬워지고 소프트웨어 개발 모든 영역이 더 쉬워지고 있다.

시간이 지날수록 더 어려워지는 것은 퇴보다. 이건 이것 나름대로 문제가 있다. 입문을 위한 시험과 자격증을 따로 만들지 않는 이상 진입 장벽이 낮아지는 것은 기술 발전에 있어서 자연스러운 흐름이다. 우린 그 속도가 빨라진 것에 주목해서 기존의 것을 '언러닝'하고 새로운 흐름을 받아들일 필요가 있다. 그동안 그래 왔던 것처럼 말이다.

상당 부분 AI가 가져갔다.

솔직히 너무 좋다. 해방아닐까? 어떻게 구현하면 되는지 뻔히 보이는 것들을 하나 하나 타이핑하고 있지 않았던가. 처음에야 내가 작성한 코드가 동작한다는 도파민에 즐겁겠지만 시간이 지나면 그저 반복 노동일 뿐이다. 그것을 자동으로 생성해주니 얼마나 좋은가. 진짜 문제는 그 다음부터라는 것을 우린 이미 알고 있다.

우리가 풀어야 하는 문제는 더 고차원적인 것이어야 한다.

프론트엔드는 진입 장벽이 낮다.

맞는 말이다. 정확히는 소프트웨어 개발 자체가 진입 장벽이 낮다. 컴퓨터 하나만 있으면 된다. 의사는 환자가 필요하다. 농사나 건축은 땅이 필요하다. 어떻게 팔 것인가는 다른 차원의 얘기지만 만들고 쉽게 공유할 수 있다. 컴퓨팅 사고라 불리우는, 처음엔 약간 어색할 수 있는 논리 흐름. 이것을 정복하겠다는 본인의 의지와 컴퓨터를 살 수 있는 약간의 경제적 여건, 이 두 가지가 최소 조건이다.

소프트웨어 개발 중에서도 프론트엔드가 진입 장벽이 낮은 이유는 혼자서도 달성할 수 있는 레벨이 꽤 높기 때문이라고 생각한다. 오픈소스 생태계는 물론이고 특정 웹사이트가 어떻게 구현되어 있는지 들여다 볼 수 있다. 개발자 도구만 열면 어떤 마크업으로 구성되어 있는지 보고 연습할 수 있다. 드러나는 코드는 빙산의 일각이지만 보고 따라할 것이 있는 수준에서 시작할 수 있는 것이다. 이것은 LLM이 학습할 수 있는 코드의 양도 방대하다는 것을 의미한다. 웹 자체가 기본적으로 공개되어 있기 때문이다.

눈에 보이는 영역이고 익숙하다는 것만으로도 심리적 장벽이 낮다. 딱히 외부의 도움도 필요하지 않다. 대규모 트래픽을 다루려면 다수의 유저가 필요한데 그럴 필요도 없다. 요즘엔 호스팅을 위한 서버도 신경쓰지 않아도 된다.

진입 장벽이 높지 않다는 것에 동의하지만 이유가 난이도 때문이라기 보다는 '접근성이 높다'에 가깝다. 사실 어느 분야든 어느 정도까지는 쉽다. 일정 수준 이상으로 더 나아가는 것이 어려운 것이다.

종말인가

그럴지도 모른다. 프론트엔드 직군 뿐만은 아닐 것이다.

AI는 컴파일 가능한 것들을 잘한다.

그러나 프론트엔드에서 중요한 많은 것들이 런타임, 정확히 말해선 브라우저나 디바이스 위에서 결정된다. 레이아웃을 결정하는 CSS, 크로스 브라우징 등 컴파일 단계에서 제대로 동작하는지 확인하기 어렵다. 고객과 직접적으로 마주하고 있는 플랫폼 특성상 애플리케이션에 주어지는 입력이 다양하고 연속적이며 이를 제어하는 것이 꽤 까다롭다.

여기에서 '연속적'이란 것은 Stateful하다는 것을 의미한다. 웹 애플리케이션이 복잡해지는 것은 사용자 경험의 연속성 때문인 경우가 많다. '상태는 관리하지 않는 것이 최선이다.' 라는 격언이 있을 정도로 상태는 복잡도를 높이는 주요 원인이 된다. 상태(state)는 본질적으로 캐싱이다. 따지고 보면 사용자 인터랙션에 따라 반응해야 하는 캐시 상태 머신을 개발하는 것이다. 캐시는 그 자체로 어렵다.

프론트엔드의 어려움을 이야기하는데 굳이 특별한 기술을 꺼낼 필요없다. 프론트엔드가 어렵다며 WebGL 얘기를 하는 사람이 있는데, 우리가 흔히 접하는 웹 애플리케이션을 만들 때 이 기술이 사용되진 않는다. (잘 모르지만 어렵다고 하더라.) 물론 이런 것들까지 다 가져와서 이야기 할 수 있지만 제외하더라도 충분히 복잡해질 수 있다.

문서

본래 웹은 어떠한 정보를 제공하기 위한 문서(document) 에 지나지 않았다. 사람들은 웹을 통해 보다 많은 정보를 공유하고 싶어졌으며 이는 기술을 발전시켰다. 자연스럽게 여러 방법들로 정보를 보여줄 수 있게 되었고 웹이라는 독자적인 영역으로 발전하게 되었다. 그러면서 자연스럽게 ‘문서’를 구성하고 있는 요소들이 많아지게 되었다.

프론트엔드의 본질은 UX가 아닐까 무려 6년 전에 쓴 글에서 가져왔다.

프론트엔드는 사용자에게 어떠한 ‘정보’를 제공하는데 있어서 보다 ‘우아하게’ 전달될 수 있도록 발전한 것이다.

사용자의 경험을 개선하고자 ajax라는 기술이 개발됐고 더 나은 개발 방식을 위해 React라는 기술을 만들어졌다.

새로운 기술이 새로운 시장을 만들기도 하지만 원래 존재하던 시장의 경우, 기술이 없던 수요를 이끌지 않는다. 수요가 있기에 기술이 발전한 것이다. 어떤 문제를 해결하기 위해 기술이 등장하기 때문이다.

앞선 예처럼 사용자 경험이 중요했고 이것을 뒷받침 하기 위해 기술이 발전했다. 그 기술이 발전하다 보니 그 기술을 전문적으로 다루는 직군이 생긴 것이다.

User Interface

Chat UI가 익숙해짐에 따라 UI가 사라질 것이라는 이야기도 있다. 분명 정보를 주고 받는데 괜찮은 UI 이지만 LLM 친화적이지 않다. 사용자와 시야를 공유할 수 없으며 채팅으로는 맥락(Context)을 전달하는데 한계가 존재한다. MCP라는 것도 이와 같은 맥락에서 등장했다.

당연하게도 새로운 User Interface가 등장할 것이고 그것이 모바일이 아닌 새로운 플랫폼 일 수 있다. 인터페이스를 담당하는 프론트엔드라는 영역은 새로운 수요를 충족시키기 위해 기술이 발전할 것이고 이에 따른 전문성을 요구할 것이다. 아마도 새로운 것을 배워야 할 수도 있을 것이다.

Expert Generalist

새로운 것을 쉽게 배울 수 있고 도전할 수 있게 되었다. 웹 전반을 다룰 수 있는 좋은 기회이고 그 이상으로 영향력을 넓힐 수 있는 기회이다. 그러다보니 '이제는 다른 분야도 해야 한다.'라는 얘기가 많다.

근데 원래 자신의 분야 말고도 인접한 분야에 대해 관심을 갖고 살펴보면 좋다. 그만큼 시야가 넓어지고 문제 해결에 도움되기 때문이다. 프론트엔드 개발자라면 자신의 분야 뿐만 아니라 백엔드, Devops, 보안 등에 대해서도 잘 알고 필요할 때 작업할 수 있으면 당연히 좋다. 원래 그랬던 것이고 AI 때문이 아니다. 난 이 흐름에 동의하며 많은 엔지니어들이 숲을 바라볼 수 있는 엔지니어가 되길 바란다. 동료들과의 커뮤니케이션에도 도움이 되어 협업력을 높일 수 있다. 오히려 주변 지식이 새로운 관점을 제시하며 본인의 전문성을 키우는데 도움을 주기도 한다.

여담이지만 이것은 제품 개발에 대한 동기 부여에도 영향을 주는데 한 기능을, 한 제품을 온전히 자신이 개발했을 때 우러나는 오너십은 남다르다.

그러나 이것이 직군간의 경계를 완전히 무너뜨릴 것이라는 의견에는 아직 회의적이다. 우린 잘 모르는 영역에 있어서 AI가 주도하는 만큼 전문성을 갖게 될 것이다. 여러 영역에 있어서 평균만큼의 전문성을 갖게 될 것이라는 말이 된다. AI와 비교했을 때 똑같이 평균적인 역량만 가지고 있다면 인간이 있어야 하는 명분이 부족하다. 특정 전문 분야에 대해서 만큼은 AI가 만든 결과물을 검토하고 더 낫게 만들 수 있어야 하지 않을까? 평균적인 조직에선 평균 수준의 제품만 만들게 된다. AI, 그리고 Engineer에서 좀 더 자세히 다뤘다.

직군의 세분화

앞서 이야기한 Generalist는 분명 팀에서 필요한 역량이라고 생각한다. 여태 그래 왔다. Fullstack이란 표현으로는 부족하여 AI oriented Fullstack Engineer 이런 직군을 만들지도 모른다. 지금은 엉터리 같지만 현실이 될 수도 있다.

조금 결이 다르지만 팔란티어의 Forward Deployed Engineer 역할을 떠올릴 수 있다. 팔란티어 엔지니어는 현장 배치 엔지니어(FDE)와 핵심 제품팀(Product Development)의 엔지니어로 나뉜다고 한다. FDE들은 속도에 중점을 둔다. 고객사의 도메인에 대한 지식과 넓은 기술 맥락을 갖고 식별한 문제를 빨리 해결하는데 집중한다. 이것은 기술 부채를 만들기도 하는데 크게 중요하게 생각하지 않는다. 생성형 AI에 의존하여 결과물을 빠르게 만들고 그것을 구성하는 코드를 신경쓰지 않는 것과 비슷하다. 이것은 무엇이 옳고 그름의 문제가 아니라 선택의 문제라고 생각한다.

반면 팔란티어의 PD 엔지니어들은 만들어진 것들을 재구성하는 것에 집중한다. 이미 구현된 여러 유스케이스를 분석하고 이것들이 확장 가능하고 재사용 가능하도록 개선한다. 이 또한 어느 한쪽을 선택한 것이다. 두 역할이 다른 부분에 집중하는 모습을 보여주는데, 이런 비슷한 모습으로 직군이 새로 생겨나거나 전문화 되지 않을까 조심스럽게 생각해본다.

마무리

어쩌다 보니 팔란티어 얘기까지 하게 됐다. 서문에서도 이야기했지만 이 글은 몇달, 몇주 후면 엉터리 글일 수 있다. 이 주제에 대해 다양한 의견들이 많이 공유되면 좋겠고 건설적인 토론이 이뤄졌으면 좋겠다.

정리

  • 프론트엔드의 본질은 UX이다.
  • 영향력을 넓히기 좋은 시기이기 때문에 기회가 된다면 다양한 분야의 역할에 도전해보는 것이 좋다.

AI 시리즈

이 글보다 더 좋은 한국어 글들